Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

13-6 [BE] [논문 상세 - 논문 정보] Request batch 작업 #82

Merged
merged 13 commits into from
Dec 2, 2022

Conversation

leesungbin
Copy link
Member

@leesungbin leesungbin commented Nov 30, 2022

개요

  • 클라이언트가 우리 서버를 통해 crossref에 다이렉트로 요청하는 것은 숨기는 작업을 진행했습니다.
  • 7-1 [BE] [메인 - 검색창 - 자동완성] Elasticsearch db 캐싱 파이프라인 생성 #62 를 발전시킨 PR입니다.
  • 사용자는 우리 서버의 Elastic search에 있는 정보만 검색가능하고, crossref API에 검색하는 작업은 서버에서 전담합니다.
    • 우리 DB에 있는 논문 정보만 보여준다는 규칙이 개발 과정에서의 여러가지 고민을 해결해줄 것으로 예상합니다.
  • Batch Flow 피그마
    image
    image

작업사항

  • Batch service가 추가되었습니다.
  • SearchBatcherDoiBatcherBatcher 라는 abstract class 를 상속합니다.
    • Batcher 에서는 Redis의 list를 queue로 사용합니다.
      • 키 1개당 32byte 정도로 잡아본다면, 1GB에 33,554,432 개의 key를 담을 수 있는데, 터지면 별도의 redis instance를 사용해야하겠지만 당장은 터질 것 같진 않네요. (현재 서버 RAM: 2GB / 평균 30% 이하로 사용중)
    • 사용자가 검색한 키워드 혹은 doi를 적절한 url 형태로 만들어서 queue에 담습니다.
    • SearchBatcher 는 키워드로 검색하기 위한 url을 queue에 담으며, 한번의 요청당 최대 1,000*SEARCH_BATCH_SIZE 개의 논문정보를 가져옵니다.
    • DoiBatcher 는 doi로 검색하기 위한 url을 queue에 담으며, 한번의 요청당 최대 1 * DOI_BATCH_SIZE 개의 논문 정보를 가져옵니다.
      • 논문 정보를 가져올 때, status code가 404이면, crossref에 없는 논문이므로 재요청을 하지 않습니다.
      • 그 외에 error에 대해서(ex request timeout)는 MAX_RETRY 만큼 시도할 때까지 큐의 맨 뒤로 담습니다.
    • depth가 깊어지는 (ex: 다음 cursor로 이동, reference를 타고 검색) 구조로의 검색 url은 queue의 오른쪽으로 담고, 사용자의 검색은 왼쪽으로 담습니다.
      • 장점: 사용자가 검색한 내용이 서버에서 crossref로 요청을 보낼 때 우선순위를 갖게 되어 db에 빠르게 반영될 수 있습니다.
      • 단점: 사용자에 의해 SEARCH_BATCH_SIZE 혹은 DOI_BATCH_SIZE 보다 많은 검색요청이 들어오는 경우, 사용자에 의해 먼저보내진 요청요청이 나중에 오게될 수도 있습니다. (이 부분까지는 오버엔지니어링으로 생각했습니다.)
  • 사용자가 반복된 키워드로 검색할 때, queue에 항상 검색 url이 담기는 것을 방지해야했습니다.
    • 검색 키워드에 대한 TTL은 24시간으로 설정했습니다.
  • elasticservice에는 batch 작업 단위로 bulk insert합니다.
  • process.env.ALLOW_UPDATE는 default가 false이고, elasticsearch에 doi가 이미 존재하면 update(덮어쓰기)하지 않습니다.
  • 기존 test code가 통과하도록 변경했습니다.

이후 작업이 필요한 내용

  • 추후, batch service에 대한 test 코드가 필요합니다.
  • Crossref로부터 too many request를 받았을 때 처리하는 로직이 필요합니다.
  • elasticsearch query에 citations 내림차순으로 정렬이 필요합니다. 문서

리뷰 요청사항

  • 환경변수 ALLOW_UPDATE 추가 필요
  • batch 로직

@leesungbin leesungbin marked this pull request as ready for review November 30, 2022 17:44
사용자가 "paper batch queue" 와 같이 사용하고 있는 keyword로 검색시 바뀌지 말아야할 값이 바뀌는 것을 방지한다.
Copy link
Collaborator

@JunYupK JunYupK left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

굉장히 많은 양의 코드를 작성하시느라 수고하셨습니다.
로컬에서는 잘 돌아가는 것 같지만, 저희 개발 서버로 올라갔을 때는 어떻게 될지 지속적인 모니터링이 필요할 것같습니다.

export const SEARCH_BATCH_SIZE = 10;
export const DOI_BATCH_SIZE = 40;
export const DOI_REGEXP = new RegExp(/^[\d]{2}\.[\d]{1,}\/.*/);
export const ALLOW_UPDATE = process.env.ALLOW_UPDATE ? (eval(process.env.ALLOW_UPDATE) as boolean) : false;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Time_INTERVAL 이나, MAX_DEPTH같이 추후에 변동이 될 수 있는 요소들을 변수로 관리를 할 수 있게 하는 부분이 참 좋은 것 같습니다.

@@ -0,0 +1,20 @@
import Redis from 'ioredis';
Copy link
Collaborator

@JunYupK JunYupK Dec 1, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Redis를 이용한 queue 군요 redis 자체를 큐로 관리하는 것은 생각 못해봤습니다.

this.queue.push(`${retries}:${depth}:${page}:${url}`, pushLeft);
}
async batchLog(queue: RedisQueue, batched: string[]) {
const urlQueueSize = await queue.size();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

queue가 redis 기반이다 보니 queue의 사이즈를 알아야 할때도 redis에 접근을 해야 하군요.
이러한 점은 단점이 될 수도 있겠네요

Copy link
Collaborator

@Palwol Palwol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

복잡한 작업인데 테스트까지 꼼꼼하게 잘 작성해 주셨네요. 👍
계속해서 배치 작업을 진행하면 서버 부하가 얼마나 발생할지가 궁금한데, 배포 후 테스트 해보면 좋을 것 같습니다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants